er modelling iii example digital voice systems data modelling deriving tables types mapping to sql...
Post on 20-Dec-2015
215 views
TRANSCRIPT
ER Modelling III Example
Digital Voice Systems
• Data Modelling
• Deriving Tables Types
• Mapping to SQL DDL
Introduction
• This lecture introduces the Digital Voice Systems Scenario
• The lecture uses a brief version of the scenario to introduce you to the model.
• The full scenario and solution is in your module pack - you need to attempt the full scenario yourself.
Brief Digital Voice Systems Scenario
Modern private digital voice systems exchanges are basically complex computer systems.
Private digital telephone networks are often used by organisations with a number of multi-building sites. These sites would be distributed around the country, each site would have one or more digital exchanges. At each site there would be a number of employees directly involved in the running of the voice systems. In particular a system would have to keep track of a telephone exchange manager for each site as well as the telephone operators.
These digital exchanges are capable of providing a continual log of their activity. Every call is logged providing information as below:
Outgoing calls: source extension, destination number, charge band.
Incoming calls: destination extension, duration of call, number of rings before answered etc.
Clearly details of many employees would need to be recorded together with the details of their associated telephone extensions. In practice employees might have more than one extension. Some employees also might share extensions and the system would have to be capable of coping with this.
Organisations would divide their employees into departments. Calls would be charged against these departments. It will be necessary that each extension would be associated with a single department for call charging.
Modern private digital voice systems exchanges are basically complex computer systems. Private digital telephone networks are often used by organisations with a number of multi-building sites. These sites would be distributed around the country, each site would have one or more digital exchanges.
• What entities can you see - a little imagination is required.
Building
Exchange
Site Room
• What about the relationships? Try to draw those in.
• Site - Building - Room; a simple hierarchy.
• You could also have a Floor entity - rooms are often named by building, floor, room number.
m1 In >1 mIn >
1
m
On v
At each site there would be a number of employees directly involved in the running of the voice systems. In particular a system would have to keep track of a telephone exchange manager for each site as well as the telephone operators.
• Just use an Employee entity and model this with relationships.
• Note: you may have considered a subtype hierarchy – employee to manager and operator
Site Building
Exchange
Room
Employee1 m
Tableneeded
< Operates
1
m< Manages (voice)
1 m1 mIn > m1 In >
1
m
On
v
These digital exchanges are capable of providing a continual log of their activity. Every call is logged providing information As below:
Outgoing calls: source extension, destination number, charge band.
Incoming calls: destination extension, duration of call, number of rings before answered etc.
• How do we model this bit?
• You will need the Extension entity.(Telephone extension)
• Try to add appropriate relationships.
Extension 1 m
Incoming
Call
1
m
Outgoing
Call
< from
^
to
Reviewing what we have so far ...
• Try to link these sections.– What is an extension
connected to?.
Extension 1 m
Incoming
Call
1
m
Outgoing
Call
< from
^
to
Site1 m
Building Building
Exchange
m1Site
1 mRoom
1
m
Employee1 m1
m
Tableneeded
< Operates
< Manages (voice)
In > In >
On
v
1m< Plugged into
Clearly details of many employees would need to be recorded together with the details of their associated telephone extensions. In practice employees might have more than one extension. Some employees also might share extensions and the system would have to be capable of coping with this.
• Starting from the Extension entity, how would you model this?
Extension Employee1m??
1 m
Now we need a name for the new entity, attributes and a primary key.Trying asymmetric viewing:
For a particular extension - what is it a list of ?
All the employees with that extension number.
For an individual employee - what is this a list of?
The employee’s extension number (or numbers)
Employeem
Now decompose it.
Extensionmm For >
Naming the complex entity
• Any ideas for a name for this entity?
• How about Directory-Entry– Quite difficult to name….
Extension Employee1m1 m For >In >
• We need an attribute for Directory-Entry.
• The primary key could be [extn#, emp#]
• The entity records an employee being associated with an extension. Any ideas for attributes?
• Would a date be appropriate? (always a useful guess)– The date the employee was given the extension number
Directory Entry
Testing the primary key
• The primary key could be [extn#, emp#] so we do the usual test.– Make up a few rows:
extn# emp# date8483 20091 29-09-19858483 12435 31-08-19908654 20091 16-09-1998
• Now try to break the chosen primary key’– Adding a row with the same primary key value as another row.
extn# emp# date8483 20091 29-09-19858483 12435 31-08-19908654 20091 16-09-19988483 20091 30-09-1985
• If we assume we only hold the latest date on which an extension is allocated to an employee - then the primary key seems to be appropriate.
Organisations would divide their employees into departments. Calls would be charged against these departments. It will be necessary that each extension would be associated with a single department for call charging.
• Try to model this ….
Extension 1 m
Incoming
Call
Outgoing
Call
Employee
Department1 m
1
m
^
In
< Charged
To < From
1
m
1
m
^
To
The diagram so far ..
• The full scenario is in the module pack. Try to re-model the scenario using the full scenario. This diagram is missing another relationship.
1
< Operates
Call
into
^For
1 m
^on
Site Building
Employee
< In
Exchange
Room< In
< Manages
1 m
ExtensionOutgoing
Call
Incoming
< From
^To
<Plugged
Directory Entry
^In
m
1
m
1
Department
In >
Charged >
to
1 m
1
1
1
1
1
1
m
m
m
m
m
m
m
Deriving tables from the diagram
• 1. How many tables?
• How many entity tables?
• Where are the relationship tables?
1
< Operates
Call
into
^For
1 m
^on
Site Building
Employee
< In
Exchange
Room< In
< Manages
1 m
ExtensionOutgoing
Call
Incoming
< From
^To
<Plugged
Directory Entry
^In
m
1
m
1
Department
In >
Charged >
to
1 m
1
1
1
1
1
1
m
m
m
m
m
m
m
2. Showing all the postings
1
< Operates
Call
into
^For
1 m
^on
Site Building
Employee
< In
Exchange
Room< In
< Manages
1 m
ExtensionOutgoing
Call
Incoming
< From
^To
<Plugged
Directory Entry
^In
m
1
m
1
Department
In >
Charged >
to
1 m
1
1
1
1
1
1
m
m
m
m
m
m
m
<<Table>>
• Are these correct?• How many postings do we have?
3. Which tables?
• Now we simply lay out the tables as below :
• Simple Entities:
Site (
Building (
Room (
Extension (
Outgoing_Call (
Incoming_Call (
Department (
Employee (
Exchange (
• Complex Entities:
Directory_Entry (
• Relationships:
Operates (
4. Identifiers
• Simple Entities:
Site (
Building (
Room (
Extension (
Outgoing_Call (
Incoming_Call (
Department (
Employee (
Exchange (
• Complex Entities:
Directory_Entry (
• Relationships:
Operates (
site#,
building#,
room#, building#,
extn#,
extn#, date, time,
extn#, date, time,
dept#,
emp#,
exch#,
emp#, extn#, - we did this earlier
exch#, emp#, - taken from the entities
• What is the primary key for the relationship table?• You need the ERD and mapping to tables rule.
5. Postings• Anything to post into Site?
– Yes, emp#.• Anything to post into Building?
– Yes, what?• Anything to post into Room?
– Yes, but pre-posted.• Anything to post into Extension?
– Yes, what?• Anything to post into Outgoing_Call?
– Yes, but pre-posted. • Anything to post into Incoming_Call?
– Yes, but pre-posted.• Anything to post into Department?
– No.• Anything to post into Employee?
– Yes, what?• Anything to post into Exchange?
– Yes, what?
• Anything to post into Directory Entry?– Yes but we already did that when we created the complex entity.– Directory_Entry(emp#, extn#, ….
Have we done all the postings? - Count them ...
1
< Operates
Call
into
^For
1 m
^on
Site Building
Employee
< In
Exchange
Room< In
< Manages
1 m
ExtensionOutgoing
Call
Incoming
< From
^To
<Plugged
Directory Entry
^In
m
1
m
1
Department
In >
Charged > to
1 m
1
1
1
1
1
1
m
m
m
m
m
m
m
<<Table>>
5. Completed Postings
• Simple Entities:
Site (site#,
Building (building#,
Room (room#, building#,
Extension (extn#,
Outgoing_Call (extn#, date, time,
Incoming_Call (extn#, date, time,
Department (dept#,
Employee (emp#,
Exchange (exch#,
• Complex Entities:
Directory_Entry (emp#, extn#,
• Relationships:
Operates (emp#, exch#,
emp#,
site#,
dept#, exch#,
dept#,
site#,
• How many foreign keys?• Have we posted all of them?
6. Assigning further attributes
These digital exchanges are capable of providing a continual log of their activity. Every call is logged providing information as below: Outgoing calls: source extension, destination number, charge band. Incoming calls: destination extension, duration of call, number of rings before answered etc.
• Where would you assign these attributes?
• Where would you record the date of employment of a telephone operator?
• The full scenario is in the module pack. Try to assign all the other attributes found there.
Mapping to SQL Data Definition Language
CREATE TABLE EXTENSION (
EXTN_NO NUMBER(6) NOT NULL ,
DEPT_NO CHAR(6) ,
EXCH_NO NUMBER(4) ,
CONSTRAINT dept_foreign_key FOREIGN KEY (DEPT_NO) REFERENCES DEPARTMENT (DEPT_NO),
CONSTRAINT exch_foreign_key FOREIGN KEY (EXCH_NO) REFERENCES EXCHANGE (EXCH_NO),
CONSTRAINT extn_primary_key PRIMARY KEY (EXTN_NO) ) ;
Extension (extn#, dept#, exch#)
CREATE TABLE DEPARTMENT (
DEPT_NO CHAR(6) NOT NULL,
DEPT_NAME CHAR(20),
CONSTRAINT dept_primary_key PRIMARY KEY (DEPT_NO));
Creating the SQL script
CREATE TABLE EXTENSION (
EXTN_NO NUMBER(6) NOT NULL ,
DEPT_NO CHAR(6) ,
EXCH_NO NUMBER(4) ,
CONSTRAINT dept_foreign_key FOREIGN KEY (DEPT_NO) REFERENCES DEPARTMENT (DEPT_NO),
CONSTRAINT exch_foreign_key FOREIGN KEY (EXCH_NO) REFERENCES EXCHANGE (EXCH_NO),
CONSTRAINT extn_primary_key PRIMARY KEY (EXTN_NO) ) ;
INSERT INTO DEPARTMENT VALUES (‘D00012’,’Marketing’); ...
DROP TABLE EXTENSION;
DROP TABLE DEPARTMENT;
INSERT INTO EXTENSION VALUES (550551,‘D00012’,8080); ...
Manipulating the Database
• Finding the telephone operators on exchange 8080.
Operates (emp_no, exch_no)
Employee (emp_no, name, dept_no)
SELECT E.emp_no, name
FROM Employee E, Operates O
WHERE E.emp_no = O.emp_no
AND exch_no = 8080;