Post on 13-Feb-2018
SIT772 Database & Information Retrieval
Week 3 Task Submission: Lucy J Nicholls
27 November, 2016
Note: Logging into the Deakin server from a remote computer requires use of WIN SCP
Exercise 1
A business rule is a brief, precise, unambiguous description of a policy, procedure or principle within a specific organization. From a database point of view, the collection of data that a database designer uncovers will only become meaningful when it reflects proper business rules.
Business rules that are derived from detailed descriptions of an organization’s operating environment help create and enforce actions within that environment.
Properly identified business rules are used to define entities, attributes, relationships and constraints. I.e . “An agent can serve many customers and each customer can only be served by one agent”, reflects business rules at work.
To be effective business rules must be easy to understand and widely disseminated. Business rules describe the main and distinguishing characteristics of data as viewed by the company.
Barwon Health Details
1. Patient Name2. Patient Address3. Patient Age4. Medicare number5. Doctor ID6. Doctor certified to make prescriptions – YES/NO7. Doctor Name8. Doctor Specialty9. Doctor Specialization years of experience10. Drug Trade Name11. Drug Strength12. Pharmaceutical Company Name13. Pharmaceutical Company Number
Question 1: List the business rules of the system
I have indentified 20 business rules relevant to this organization-
1. A patient will have one medicare number that is UNIQUE to the patient2. A patient will have a name that may not be unique to that patient3. A patient will have an address that may not be unique to that patient4. A patient will have an age that may not be unique to that patient5. A Doctor will have a Doctor ID that is UNIQUE to that Doctor
6. A Doctor will have a name that may not be unique to that Doctor7. A Doctor will have a specialty that may not be unique to that Doctor8. A Doctor will have a number of years of experience that may not be unique to that Doctor9. A Doctor may or may not be certified to make prescriptions 10. Drugs will have a trade name UNIQUE to that drug11. Drugs will have a strength that may not be unique to that drug12. A drug is supplied by only one Pharmaceutical company 13. A Pharmaceutical company can supply more than one drug14. A patient will have one Primary Doctor15. A Doctor may have more than one Primary Patient16. A prescription will have a date that may not be unique to that prescription17. A prescription will have a quantity that may not be unique to that prescription18. A Doctor may prescribe one or more drugs19. A Patient may be prescribed one or more drugs 20. A Patient may obtain prescriptions from one or more Doctors
Question 2: Draw an ER diagram to capture the data requirements of the database to be designed. It should capture as much business rules (constraints) as possible. If you chose to omit any business rules, provide an explanation. Explain any “non-obvious” choices.
The Entity Relationship Diagram represents the conceptual database as viewed by the end-user. ERD’s depict the databases main components; Entities, attributes and relationships. Entities represent a real-world object and are often used interchangeably. There are different kinds of notation that are used in the construction of ERD diagrams:
1. Chen notation: Favors conceptual modelling2. Crow’s Foot notation: Favors a more implementation-oriented approach3. UML notation: Can be used for both conceptual and implementation modelling
An entity in the ERM refers to a table and the entity is written in capital letters. Attributes are characteristics of entities; required attributes must have a value and an optional attribute does not require a value
A domain is a set of possible values for a given attribute Primary Keys (Identifiers): One or more attributes that uniquely identify each entity instance. In the relational model entities are mapped to tables
and the entity identifier is mapped to the table’s Primary Key (PK). These are underlined in the ERD. Key attributes are also underlined in a format called the relational schema
A composite key is a primary key that is composed of more than one attribute Attributes are classified as simple or composite. A composite attribute is an attribute that can be sub-divided to yield additional attributes. A simple
attribute cannot be sub-divided A derived attribute can be derived using an algorithm and need not be stored in the database. I.e. an employee’s age derived from DOB Relationships are participated in by the entities and the relationship is defined by an active or passive verb. Once you know both directions of the
relationship you can define whether a relationship is 1:M The term connectivity is used to describe the relationship classification Cardinality expresses the minimum and maximum number of entity occurrences associated with one occurrence of the related entity The degree of the relationship is the number of entities associated with that relationship
o Unary relationship – 1 entityo Binary – 2 enititieso Ternary – 3 entities
See next page for diagram
Entity Relationship Diagram: Barwon Health
Prescription is a “Weak Entity” as it meets the two criteria as follows:
1. The entity is existence dependent – it cannot exist without the entities with which it has the relationship2. The entity has a primary key that is partially or totally derived from the parent entity in the relationship
Question 3: Write the Data Dictionary
DATA DICTIONARY: BARWON HEALTH COMPANY DATBASE – PROPOSED DESIGN
TABLE NAME ATTRIBUTE NAME CONTENTS TYPE FORMAT RANGE REQUIRED PK OR FK FK REFERENCED TABLEDOCTOR DOC_ID
DOC_FIRST_NAMEDOC_LAST_NAMEDOC_EXPERIENCESPE_ID
DR codeDR fist nameDR surnameDR # yearsDR specialization
CHAR(5)VCHAR(20)VCHAR(20)NUM(9,2)CHAR(3)
XxxxxXxxxxxxxxXxxxxxxxx99Xxxxxxxxx
1-99
YYYYY
PK
FKDOCTOR_SPECIALIZATION
DOCTOR_SPECIALIZATION SPE_IDSPE_NAME
Spec. IDSpec. Name
CHAR(3)VCHAR(40)
XxxxxxxxxXxxxxxxxx
YY
PK
PATIENT** PAT_MEDICAREIDPAT_FIRST_NAMEPAT_LAST_NAMEPAT_AGEPAT_ADDRESSDOC_ID
Medicard #First nameSurnameAgeAddressPrimary DR
CHAR(10)VCHAR(20)VCHAR(20)NUM(9,2,2)VCHAR(40)CHAR(5)
XxxxxxxxxXxxxxxxxxXxxxxxxxx999XxxxxxxxxXxxxx
1-115
YYYYYY
PK
FK DOCTORPRESCRIPTION DRU_CODE
PAT_MEDICARECARDDOC_IDPRE_DATEPRE_QUANTITY
Drug CodePatient MC #Doctor IDPresc. DatePresc. Quantity
CHAR(5)CHAR(10)CHAR(5)DATENUM(9222)
XxxxxXxxxxxxxxXxxxxmm-dd-yy9999 0-1000
YYYYY
PK,FK1PR,FK2PR,FK3
DRUGPATIENTDOCTOR
DRUG* DRU_CODEDRU_TRADE_NAMEDRU_STRENGTHPHA_ID
Drug codeDrug nameDrug strengthSupplier ID
CHAR(5)VCHAR(40)NUM(9)CHAR(5)
XxxxxXxxxxxxxx9Xxxxxx
1-9
YYYY
PK
FK PHARMACEUTICAL_COMPANYPHARMACEUTICAL COMPANY
PHA_IDPHA_NAMEPHA_NUMBER
Company IDCompany nameCompany number
CHAR(5)VCHAR(40)NUM(10)
XxxxxXxxxxxxxx99 1-99
YYY
PK
*Assumes each drug is supplied by only one pharmaceutical company **Assumes that each patient must have a primary DR specified when input into the system
Exercise 2
Create Sample tables using an SQL Load Script
Apply the SQL commands from practical 2 to check whether these sample tables are in the database, view the structure and sample of each table:
SELECT FROM Dependent;
SELECT dname FROM Dependent;
SELECT snameFROM Student;
Does not exist
SELECT dname, relationshipFROM Dependent;
SELECT dname, ageFROM DependentORDER BY Age;
This statement produces the rows of results ordered by age
SELECT dname, ageFROM DependentORDER BY sex;
SELECT dname, age, sexFROM DependentORDER BY sex;
SELECT dname, ageFROM DependentORDER BY age;
SELECT dname, relationshipFROM DependentORDER BY relationship;
SELECT dname, ageFROM DependentORDER BY age DESC;
SELECT dname, sex, ageFROM DependentORDER BY sex, age DESC;
SELECT dname, sex, age FROM Dependent
ORDER BY sex DESC, age DESC;
In relational database terminology a table is called a relation, and is denoted by the name of the relation followed by the columns (or attributes) SELECT *
FROM DependentWHERE sex = ‘F’;
SELECT *FROM DependentWHERE age <=5ORDER BY age;
SELECT *FROM DependentWHERE age <=5AND sex = ‘F’;
SELECT *FROM DependentWHERE age > 20 OR sex = ‘F’;
SELECT dname, ageFROM DependentWHERE age >= 3AND age <=5;
SELECT dname, ageFROM DependentWHERE age NOT BETWEEN 3 AND 5
SELECT dname, ageFROM DependentWHERE age IS NULL;
IS NOT NULL in the above command will retrieve accordingly SELECT *
FROM Dependent;ThenSELECT COUNT(*)FROM Dependent;
SELECT COUNT(age)FROM Dependent;
Here COUNT(age) only counts the rows in which age is not null Column aliases and table aliases are temporary names assigned within a query to columns and table respectively. They are created on the fly within
a query and they do not exist after the query is run SELECT dname, age, sex
FROM DependentWHERE age >5;
SELECT dname, AS Dependent_name, age AS Depedent_age, sex AS Dependent_sexFROM DependentWHERE age > 5;
See prac notes for other syntax variations
SELECT d.dnameFROM Dependent dWHERE d.age >5;
UNION
SELECT * FROM Enrolment UNION SELECT * FROM ClassList;
Refer to prac3 notes for the INTERSECT, DIFFERENT, PRODUCT and SELECT SQL Queries