Введение в базы данных (1176852), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Нормализация БД.

1. SQL, оператор Select. Создание таблиц.

Cold ввел три операции для отношений:

1. Операция проектирования:

- новое отношение и повторяющиеся картежи удаляются

1.  выбор (селекция)

На SQL обе операции задаются оператором SELECT

1. Операция соединения

Пример:

Продавцы

---------------------------------------------

SNUM SNAME CITY COMM

---------------------------------------------

1001 Peel London .12

1002 Serres San Jose .13

1004 Motika London .11

1007 Rifkin Barcelona .15

1003 Axelrod New York .10

---------------------------------------------

Заказчики

----------------------------------------------

CNUM | CNAME | CITY | RATING | SNUM

-------|------------|---------|--------|------

2001 | Hoffman | London | 100 | 1001

2002 | Giovanni | Rome | 200 | 1003

2003 | Liu | SanJose | 200 | 1002

2004 | Grass | Berlin | 300 | 1002

2006 | Clemens | London | 100 | 1001

2008 | Cisneros | SanJose | 300 | 1007

2007 | Pereira | Rome | 100 | 1004

----------------------------------------------

Заказы

-----------------------------------------------

ONUM | AMT | ODATE | CNUM | SNUM

-------|-----------|-------------|------|------

3001 | 18.69 | 10/03/1990 | 2008 | 1007

3003 | 767.19 | 10/03/1990 | 2001 | 1001

3002 | 1900.10 | 10/03/1990 | 2007 | 1004

3005 | 5160.45 | 10/03/1990 | 2003 | 1002

3006 | 1098.16 | 10/03/1990 | 2008 | 1007

3009 | 1713.23 | 10/04/1990 | 2002 | 1003

3007 | 75.75 | 10/04/1990 | 2004 | 1002

3008 | 4723.00 | 10/05/1990 | 2006 | 1001

3010 | 1309.95 | 10/06/1990 | 2004 | 1002

3011 | 9891.88 | 10/06/1990 | 2006 | 1001

-----------------------------------------------

Описание таблиц:

snum уникальный номер назначенный каждому продавцу

( " номер служащего " ).

sname имя продавца.

city расположение продавца( город ).

comm комиссионные продавцов в десятичной форме.

cnum уникальный номер назначенный каждому заказчику.

cname имя заказчика.

city расположение заказчика( город ).

rating код указывающего уровень предпочтения данного заказчика

перед другими. Более высокий номер указывают на большее предпочтение (рейтинг).

snum номер продавца назначенного этому заказчику

( из таблицы Продавцов )

onum уникальный номер данный каждому приобретению.

amt значение суммы приобретений.

odate дата приобретения.

cnum номер заказчика делающего приобретение

( из таблицы Заказчиков ).

snum номер продавца продающего приобретение

( из таблицы Продавцов).

1 нормальная форма:

1. все значения атрибутов должны быть атомарными

2. не должно быть повторений

Функциональная зависимость:

, Y зависит от Х, если каждое значение X определят Y.

2 нормальная форма:

1. нет атрибутов, функционально зависящих от части (строго меньше) первичных ключей.

3 нормальная форма:

1. все атрибуты зависят только от первичного ключа (нет транзитивной зависимости типа: )

Вот, как правильно надо делать, чтобы добавить в БД информацию по телефонам заказчиков. Добавление этой информации в уже существующие таблицы было бы ошибкой.

-------------------------------

CNUM | PH | TYPE

-------|-----------|-----------

2001 | 9398721 | H

2001 | 9398722 | H

2001 | 5418198 | Off

2001 | 1067612 | Mob

-------------------------------

…

1. Классы и объекты. Особенности и характеристики ОО программирования клиентской части БД.

Программа

Рынок программных компонент

COM (Common Object Model)

Corba

Java Beans

Интерфейс – совокупность отрытых методов. Обозначение интерфейса на UML.

Объект

Объект – экземпляр класса.

Класс – шаблон, для конструирования объектов.

Объект определяется своим поведением и состоянием.

Алан Кей, которого кое-кто называет отцом объектно-ориентированного программирования, считает следующие положения фундаментальными характеристиками ООП

1. Все является объектом

2. Вычисления осуществляются путем взаимодействия между объектами, при котором один объект требует, чтобы другой объект выполнил некое действие.

3. Каждый объект имеет независимую память, которая состоит из других объектов.

4. Каждый объект является представителем класса, который выражает общее свойства объектов.

5. В классе задается поведение объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.

6. Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определенного класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.

Объектно-ориентированное программирование обеспечивает механизм для отделения существенно информации от специализированной. Тем самым при использовании объектно-ориентированной техники мы можем создавать большие программные компоненты, пригодные для повторного использования.

Три кита ООП:

1. Инкапсуляция -

Слияние данных и функций, работающих с этими данным (методами), порождающее абстрактные типы данных, определяемые пользователем.

1. Полиморфизм

Полиморфизм – различная реализация методов с одним и тем же интерфейсом.

1. Наследование

Создание новых классов с использованием уже существующих и их функциональности.

Use Case  UML диаграммы

В UML-е наследование отображается следующим образом:

Родитель

Потомок

Класс потомок наследует всю функциональность родителя. При этом наследуются и все отрытые методы.

Техническое задание

Крупная функциональность (функциональное требование)

Не функциональные требования

Интерфейс

Производительность

Ресурсоемкость

Надежность

Сопровождение

Use Case

1. 1. Определить типы пользователей

   2. Типы других систем, с которыми взаимодействует система

Actor:

1. Для каждого actor-a определить задачи решаемые системой.

UC (Use Case)

– последовательность действий, которая дает законченный и значимый результат

Сценарий – экземпляр UC

State Holders – представители заказчика

Use case diagram:

Диаграммы сценариев позволяют отобразить, описать и "задокументировать" желаемое поведение системы с точки зрения взаимодействия с ней внешних объектов (актеров). Сценарием также можно назвать какой-либо набор логически связанных между собой действий, приводящих к какому-то "логическому состоянию" системы.
Т.е. это описание "на высоком уровне абстракции, “ какие случаи, ситуации обрабатывает ваше приложение, какие реально действующие лица взаимодействуют с системой.

В диаграммах сценариев UML, актер - это роль объекта или объектов взаимодействующих с частью системы - соответствующим блоком сценария (use case). При этом актер - внешний по отношению к системе объект. Что мы подразумеваем под внешним объектом - это объекты, взаимодействующие с проектируемой системой, но при этом не являющиеся ее частью и которые обычно напрямую взаимодействуют с ее частью, но не имеют "непосредственного прямого" влияния на работу системы. Роли объекта - это роли, которые выполняет объект в различных сценариях. Т.е. объект может быть один, а выполняемых им ролей - несколько и таким образом он может моделироваться несколькими актерами.

Требования

Проектирования

Кодирование

Тестирование

Поставка (развертывание)

1. Rational Unified Process. Описание жизненного цикла UC. Основные процессы и их характеристики.

Rational Unified Process

RUP - методологическая основа для всего, что выпускает Rational. То есть данный продукт является энциклопедией (методологическим руководством) того, как нужно строить эффективное информационное производство. Также RUP регламентирует этапы разработки ПО, документы, сопровождающие каждый этап, и продукты самой Rational для каждого этапа. В RUP заложены все самые современные идеи. Продукт постоянно обновляется, включая в себя все новые и новые возможности. К достоинством данной методологии стоит отнести чрезвычайную гибкость, то есть RUP не диктует, что необходимо сделать, а только рекомендует использовать то или иное средство.

Выше уже упоминался ряд проблем на пути выпуска ПО. Вот что предлагает RUP для решения подобных проблем:

Выпускать программное обеспечение, пользуясь принципом промышленного подхода. То есть так, как поступают любые заводы и фабрики: определяя стадии, потоки, уточняя обязанности каждого участника проекта. Именно промышленный подход позволит достаточно оперативно выпускать новые версии ПО, которые при этом будут надежными и качественными

Расширять кругозор специалистов для снятия барьеров. Ведь в подавляющем большинстве случаев специалисты из разных отделов просто говорят на разных языках. Соответственно, снятие языкового барьера должно вести к ускорению работы над программным обеспечением

Использовать итеративную разработку вместо каскадной, существующей в настоящее время. Принцип итерации заключается в повторяемости определенной последовательности процессов с целью доведения элемента до безошибочного состояния.

Обязательное управление требованиями. Всем известно, что по ходу разработки в систему вносятся изменения (самой группой разработчиков или заказчиком - неважно). Rational предлагает мощную систему контроля управления требованиями: их обнаружение и документирование, поддержку соглашений между разработчиками и заказчиками,

Характеристики

Список файлов лекций