The Data Dictionary

• A DBMS must provide facilities to allow users to find out the

Master in Information properties of the stored items (metadata).
Technology
• These facilities may also be used by components of the DBMS itself.
ICT - 209 • Collectively, these facilities are called the Data Dictionary (or the
System Catalogue).
Database Applications • The Data Dictionary must hold information about the tables, views,
forms, queries, and reports stored in the database.
Overview: – for example, it stores information about the name, types, sizes, and
constraints that apply to each of the tables in the database
• Data Dictionary • It must also store information about the users of the system.
• Data Administrator – For example, it stores the names and details of authorised users including
information about which areas of the database are accessible to each user
• Database Administrator
• Some of this information is accessible only to the DBA.
• Distributed Databases
Slide 1 Slide 2

The Data Dictionary in Oracle - I The Data Dictionary in Oracle - II

• In a relational DBMS, the Data Dictionary is often made to look as if it • Other DD tables have many columns:
were made up of tables.
– USER_TABLES (synonym TABS)
• These tables are views.
– USER_TAB_COLUMNS (synonym COLS)
• For example, in Oracle there are many tables with names such as
USER_xxx which give information relating to a particular user. • The columns of these tables are divided into groups: e.g.
USER_TAB_COLUMNS has Identification, Definition-Related, and
– For instance, the table USER_CATALOG shows all tables and views Statistics-Related columns
owned by the current user. (A synonym for this is CAT)
– these last are populated only when the table is Analysed
– This table has only two columns: name and type

Slide 3 Slide 4

The Database Administrator - I The Database Administrator - II

• Within any organisation using a shared DBMS, we will expect to find a • However, in most organisations (perhaps in all organisations of any
Database Administrator (DBA). significant size), many users will be sharing data
• At the very minimum (where the users use the DBMS for their own – and the shared data will be crucial to the core business
independent purposes), the DBA will be responsible for the orderly
running of the program. • The data may be divided into different systems - for example the
University has
• For instance, an “instance” of ORACLE runs all the time (even when
there are no users logged on to it) – Finance
– Student Records
– and users’ data is not stored in separate files, but in common
– Recruitment and Admissions
data areas…
– Vacation letting
– and is backed up and journalled (logged) together… – Estates and Buildings
– so at the very least there must be someone who makes sure – Payroll
that all this happens properly. – Personnel
• Under these circumstances the managerial role of the IS professional is
very important indeed (and there will be a team)
Slide 5 Slide 6

1
 The DA and the DBA - I
• There is often a distinction between the roles of the Database
Administrator and the Data Administrator, both of which have
specific responsibilities that complement each other.
– The DA has a more strategic and managerial role.
– The DBA has a more technical role.
• The DA will be responsible for the Information Strategy of the
organisation as a whole (i.e. transcending the various subsystems)
• and will be concerned with large-scale developments (e.g. moving
subsystems between platforms, developing new subsystems, ensuring
resilience, developing & maintaining standards, policies & procedures
etc.)
Slide 7
The DA and the DBA - III
• The DBA will also
– write “sub-schemas” for user views
– document the views
– allocate ownership rights and duties
– with the DA, adjudicate between different interests
– use the DBMS management tools to monitor, tune,
reorganise, protect, backup, and reload
Slide 9
Distributed Databases
• Distributed Database
– A logically interrelated collection of shared data (and a
description of this data), physically distributed over a
computer network.
– Could be across two computers in the same room or lots of
computers across the world
– Under the control of more than one CPU
• Distributed DBMS
– Software system that permits the management of the
distributed database and makes the distribution transparent to
users.
Slide 11
The DA and the DBA - II
• The DBA role is concerned more with managing a particular
(sub)system on a particular platform
• The DBA will have roles both during the setting-up of a system, and,
later, while it is running.
• The DBA will
– with the DA, participate in deciding the information content
of the database
– write the conceptual specification (“conceptual schema”)
– decide how the data should be stored: use the facilities of the
DBMS to provide the mapping from the logical to the
physical
Slide 8
Management tools used by the DBA
• Any mature DBMS will provide tools to:
– bulk load data from files in other formats
– restructure data: for example to distribute data across several
sites
– provide differential access to data in ways that can be
configured and restructured
– maintain dynamic backup and restore facilities to enable rapid
recovery of a DBMS whose platform crashes
– (these facilities may be automatic but configurable by the
DBA)
– give access to data about the DBMS, its contents, its users and
its performance (via the Data Dictionary)
– retune parameters to improve performance (eg, Hints in
ORACLE) Slide 10
Slide 12
2

Key Concepts
• Collection of logically-related shared data.
• Data split into fragments.
• Fragments may be replicated.
• Fragments/replicas allocated to sites.
• Sites linked by a communications network.
• Data at each site is under control of a DBMS.
• DBMSs handle local applications autonomously.
• Each DBMS participates in at least one global application.
Slide 13
Advantages of DDBMS
• Reflects organizational structure — database fragments are located in
the departments they relate to.
• Local autonomy — a department can control the data about them (as
they are the ones familiar with it.)
• Improved availability — a fault in one database system will only affect
one fragment, instead of the entire database.
• Improved performance — data is located near the site of greatest
demand, and the database systems themselves are parallelized,
allowing load on the databases to be balanced among servers. (A high
load on one module of the database won't affect other modules of the
database in a distributed database.)
• Economics — it costs less to create a network of smaller computers
with the power of a single large computer.
• Modularity — systems can be modified, added and removed from the
distributed database without affecting other modules (systems).
Slide 14

Disadvantages of DDBMS
• Complexity — extra work must be done by the DBAs to ensure that the
DDBMS
distributed nature of the system is transparent. Extra work must also be done
to maintain multiple disparate systems, instead of one big one. Extra database
design work must also be done to account for the disconnected nature of the • DDBMS is a Distributed Database Management System with
database — for example, joins become prohibitively expensive when – Extended communication services.
performed across multiple systems.
• Economics — increased complexity and a more extensive infrastructure
– Extended Data Dictionary.
means extra labour costs. – Distributed query processing.
• Security — remote database fragments must be secured, and they are not – Extended concurrency control.
centralized so the remote sites must be secured as well. The infrastructure
must also be secured (e.g., by encrypting the network links between remote – Extended recovery services.
sites). • Plus all the functionality you would expect from a
• Difficult to maintain integrity — in a distributed database, enforcing integrity centralized DBMS
over a network may require too much of the network's resources to be feasible.
• Inexperience — distributed databases are difficult to work with, and as a
young field there is not much readily available experience on proper practice.

Slide 15 Slide 16

Two Types of DDB Which Type and Why?

• Homogeneous DDBMS • Homogeneous DDBMS
– All sites use same DBMS product. – Databases that are homogeneous were probably designed to be
– Much easier to design and manage. distributed from the start
– Approach provides incremental growth and allows increased – The designers had the luxury of being able to choose a common
performance. DBMS
• Heterogeneous DDBMS – Foreign keys allow tables in one database to be linked to tables in
– Sites may run different DBMS products, with possibly different another
underlying data models. – The physical distribution is probably for security and service
– Occurs when sites have implemented their own databases and integration
is considered later. protection.
– Translations required to allow for: – Far fewer problems to solve when building and maintaining such a
• Different hardware. database
• Different DBMS products. – This type of design is known as top down.
• Different hardware and different DBMS products.
– Typical solution is to use gateways.

Slide 17 Slide 18

3
 Which Type and Why?
• Heterogeneous DDBMS
– The different databases probably already exist and are in
use by different users
– It becomes desirable to join them into one apparently
single database, without simply throwing them all away
and starting again
– They could each have a different DBMS
– They will be more than one DD, DA and DBA
– They may not be an easy way of matching fields from
one to equivalent fields in another
– Joining such databases is known as a Bottom Up join
Slide 19
Joining a DDBMS Bottom Up
• The job of the DDBMS is to sit above the several separate databases
and provide the user with a single view as if there were really only one
database
• It does not integrate the databases into one new single database. They
stay where they are.
• One method of achieving this is to use a gateway, which translates
from one DBMS to another
• There are also attempts being made to develop open specifications that
will allow one DBMS to communicate with another without the need
for a gateway.
• A much more difficult problem is joining the data from more than one
DB, for example, the current account DB has William Smith, but
marketing communicate with Bill Smith.
Slide 21
Partitioning Schemes
• Any part of a distributed database is called a fragment
• For homogeneous DDBs, the most common forms of partitioning are
horizontal and vertical:
• Horizontal partitioning is where different full records from a table are
stored in different locations.
• Example:
Imagine the car dealership chain, Arnold Clark. They will use a dealer
management system such as Kerridge. The tables in each dealership
will have the same structure (homogeneous) but different customers
will appear in each. If head office want to write to every customer,
regardless of where they bought the car, they need the DDBMS to be
able to respond to a query that generates every customer across all the
databases in each dealership.
Slide 23
Example
• A bank has a database of current account users, another with
mortgage holders and a third with customer relations data.
• If the marketing department want to see what services a customer
has bought, and when they last wrote to them, they have to look
the customer up in three different databases.
• The databases can become out of synch, for example if a person
moves house and tells the bank once. The mortgage account DB
might get updated, but the current account DB might not, and the
customer relations DB almost certainly will not.
• By joining the databases, the bank can have a ‘single customer
view’, which is something they like.
Slide 20
Joining a DDBMS Bottom Up
• Bottom up joins have many difficulties because the databases were not
designed to be joined.
• Each will have its own DBA, so there needs to be human integration
too
• The purpose for which a DB was designed may not match the reasons
that it is needed when it has been joined
• E.g. city council social services
Slide 22
Partitioning Schemes
• Any part of a distributed database is called a fragment
• For homogeneous DDBs, the most common forms of partitioning are
horizontal and vertical:
• Vertical partitioning is where different attributes are stored in different
locations.
• Example:
I probably appear on a few databases in the university: payroll, car
parking, timetabling, sports centre …
If the university wanted to be able to make a single query and see
everything they have about me, it would be from a number of different
databases. Chances are, they couldn’t do it because the DBs are not
under a DDBMS.
Slide 24