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