LU sesijas - Fizmati.lv

1.
Jedziens par datu apstrades sistemam.
Savstarpejo sadarbojosos objektu kopums – sistema (Stacionaras, dinamiskas).
Sistēmas dalas uz DAS un ne DAS.
Vadibas  DAS  informacijas
DAS: stacionara (laika nemainas), dinamiska(laika mainas)
Datu glabasana, apstradasana. Tiek abstradati objekti.
50 gados aprekinaja un tikai tāds pielietojums.
65 gada pievienoja gramatvedibu, parodijas pirmās DAS Latvija. Jau divpielietojums līdz 85 aprekina un apstrāde.
No 85 parodijas mainfreimi. Jaunie pielietojumi – spēles, virtuāla realitāte, aprekinasana, datu apstrāde, teksta
redaktori …
Vidēji sistēma dzīvo 5g.
2.
Datu apstrades sistemu dzives cikla modeli.
Prasibas Analize1ProjektsAnalize2KodesanaTestesanaUzturesana.
Parasibas un analize1:
Projekts un analize2: projektesana.
Kodesana un testesana: programmesana(programma).
Uzturesana: ieviesana.
Veiksmiga sistema dzivo 5 gadus, meinfreimiem 20 gadus. Dzives cikla modela ilgums atkarigs no uzdevumu
specifikacijas, piemeram programmai jamaina interveisu, platformu, os, parrakstit lietojot jaunas tehnologijas un
metodes un t.t.
3.
Prasibu uzkrasana un analize. Prototipesana.
Prasibu uzkrasana:
Tiek izstadatas sistemas prasibu specifikacijas:
- Izpildijamas funkcijas (funkcionalias modelis)
- lietotajamie jedzieni un to sakaribas(datu modelis)
- sistemas funkcionesana (dinamiskais modelis) prasibas programmaturai
- tehniskai drosibai
- citas specifikas prasibas
Prasibu analize:
Tiek izstradatas rekomendacijas sistemas izveidei:
- sistemas koncepcija
- tehniska realizejamiba un variantu analize
- ekonomiska lietderiba- vai ir ekonomiski izdevigi sistemu taisit
- izmaksas un termini
- darbu organizacija.
Darbu organizacijas plans, projektvadiba.
Prototipesana:
Sistemas prototipas izveidosana, paradit sistemas sagatavi pasutitajam.
4.
Sitemas projektesana un analize.
Projektesana:
Tiek izstradatas sistemas projekts (projektejuma apraksts):
- izpildamas funkcijas (menu)
- ER modelis un datu strukturus
- Sistemas funkcionesanas algoritms
- Lietotaju saskarsme (ekranu formas un atskaites)
- Standartprogrammaturas, datortehnikas, tiklu un citu elementu izvele.
Analize:
- Tiek akceptets sistemas projekts(pieprasijuma apraksts):
- Standartprogrammaturas, tikli un datortehnikas
- Instalacija un aprolbacija
- Prototipesana - sistemas prototipas izveidosana, paradit sistemas sagatavi pasutitajam.
- Simulesana - reakcijas laiki, drosibas situacijas
Programmesanas vides izvele
Pilotprojekti
Проэктирование:
При проэктировании структуры новой БД определяют сущности (объекты, явления) предметной области,
которые должны найти свое отражение в БД.
Анализ:
Анализ предметной области обычно осуществляется:
- На основании существующих сведений о предметной облости.
- Исходя из целей проэктирования програмной системы
- На основание представления о том, какое место БД и работающее с ней приложения займут в структуре
эксплуатирующей ее организации
Следовательно с одной стороны процесс проэктирования структур БД является процессом творческим,
неодназначным. С другой стороны узловие его моменты могут быть формализированы. (+ см Нормализацию в
таблицах N17)
5.
Datu apstrades sistemu realizacija.
Kodesna (programmesana):
Tiek izstradata programmatura:
- modulu kodesana un testesana
- modulu integresana
- testesana izstrades grupas ietvaros
- dokumentacijas izstrade (lietotaju celvedis)
cilveksLI(Delphi, Builder, Visual C++, Visual Basic, Access, FoxPro)DBPS(datu bazes parvaldibas sistemas
(MS SQL, ORACLE, Sybase, Borland InterBase))
6.
Datu apstrādes sistēmu testesana.
Testesana – parliecinaties ka sistēma dara to, kas viņai jādara.
Tiek akcepteta izstradata programmatura:
Testesanas plana izstrade:
- Neatkariga programmaturas testesana (testu piemeru izstrade un uzskrasana, testu izpilde un rezultatu novertesana);
- Kludu zinojumi un izmaina pieprasijumu: dokumentacijas testesana.
Melnas un baltas kastes testesana.
Melnas: nekas nav zināms par programmatūras uzbūvi.
Baltas: viss ir zināms, testus var sastadit, zinot struktūru.
7.
Datu apstrādes sistēmu uzturesana.
Ieviesana:
Datu migracija, datu parnesana no vecas sistemas uz jaunu, sistema mirst, vai atgriezas pie jauna.
Uzturesana1:
Uzturet sistemu pec dzivibas, registre kludas, ja sistema dzivo 5g tad uzturesana ir 3g. Kludas – fikseti dzilojumos
izstad. noverte un pec tad parodas jaunas uzlabotas sistemas ar wordu – tapat darija.
Uzturesana2:
Tiek nodota lietosana un lietota izstradata sistema:
- pilotprojekti
- datu migracija
- kludu zinojumi un izmainu pieprasijumi
- konfiguracijas vadiba
- pareja pie jaunas versijas izstrdades
8.
Datu plusmu diagrammas.
(f-jas vards)
[objekta vards]
--- zinojuma vards
---------db vards
Ka pieners jaizmanto manu DPD kursa projekta.
4) Attieciba varetu but viena tabula, piemeram ja vajag glabas ierarhijas strukturu viena tabula, tad katrs ieraksts
saistas ar ierakstu tada pasa tabula kurs define augstaka limena elementu, un ierarhijas augstakais elements nesaisata
ne ar vienu citu elementu.
Tada veida attiecibas nav realizetas relacijas datu bazes vadibas sistemas.
11.
Informācijas kodesanas principi.
9.
ER Modeli.
Entitija – butiba
[ vards ]
[ …
[atributi
[ ….
Relacija – attieciba: o---o
Kardinalitate:
1) -----Attieciba viens-pret-viens, tad kad galvena tabula viens ieraksts var but saistits tikai ar vienu ierakstu saistita tabula.
To lieto lai viena tabula nebutu loti daudz informacijas, tad informaciju dala gruppas un galvena tabula glabajas indeks
otra tabula.
2) ------<Atticieba viens-pret-daudziem, tad kad galvena tabula viens ieraksts var but saistits ar daudziem ierakstiem saistita
tabula. Tadu relaciju izmanto lai galvena tabula nebutu loti liela, t.i. ka ja katra ieraksta ir kads neiss lauks(i), bet
vertibu kopas izmers ir fiksets, tad var tadu kopu uzstadit ka tabulu un galvena tabula glabat tikai indeksu uz otro
tabulu. Tads relacijas veids ir vispopulars un dazdpielietojams. Ar to var modelet datu ierahriju.
3) -<- --- -<Atticieba daudz-pret-daudziem, tad kad:
- galvena tabula ieraksts var but saistits ar daudziem ierakstiem saistita tabula.
- saistita tabula ieraksta var but saistits ar daudzim ierakstam galvena tabula
4) Attieciba varetu but viena tabula, piemeram ja vajag glabas ierarhijas strukturu viena tabula, tad katrs ieraksts
saistas ar ierakstu tada pasa tabula kurs define augstaka limena elementu, un ierarhijas augstakais elements nesaisata
ne ar vienu citu elementu.
Tada veida attiecibas nav realizetas relacijas datu bazes vadibas sistemas.
10.
Relacijas kardinalitate.
Relacija – attieciba.
Kardinalitate:
1) -----Attieciba viens-pret-viens, tad kad galvena tabula viens ieraksts var but saistits tikai ar vienu ierakstu saistita tabula.
To lieto lai viena tabula nebutu loti daudz informacijas, tad informaciju dala gruppas un galvena tabula glabajas indeks
otra tabula.
2) ------<Atticieba viens-pret-daudziem, tad kad galvena tabula viens ieraksts var but saistits ar daudziem ierakstiem saistita
tabula. Tadu relaciju izmanto lai galvena tabula nebutu loti liela, t.i. ka ja katra ieraksta ir kads neiss lauks(i), bet
vertibu kopas izmers ir fiksets, tad var tadu kopu uzstadit ka tabulu un galvena tabula glabat tikai indeksu uz otro
tabulu. Tads relacijas veids ir vispopulars un dazdpielietojams. Ar to var modelet datu ierahriju.
3) -<- --- -<Atticieba daudz-pret-daudziem, tad kad:
- galvena tabula ieraksts var but saistits ar daudziem ierakstiem saistita tabula.
- saistita tabula ieraksta var but saistits ar daudzim ierakstam galvena tabula
{objekti} -> (kodi)
1) Primāri
2) Numuracija intervālos: [obj1][obj2]…[obj n] (grupas)
3) Pēc kārtas, grupas: gala 01, zivis – 02,… -> pārtika 001, apgerbs 002, …:
+ pēc koda var noteikt objektu, relatīvi visu var atvērt.
- jātaisa modifikatoru, liela kludas iespēja, cilvēkam neērts.
4) Pozicialais princips:
Labāk kodēt nevis ar cipariem, bet ar burtiem. (mnemoniska apzimejumiem)
LU.FMF.DZ nevis 01071. Tiek lietota draudzīga valoda
5) ISN.
Cilvēku pasaule – saistās ar ekrānu
Datoru pasaule – ISN.
ISN (integral system number)– pati sistēma genere kodu datu baze
Ir tabulas, skaits – cit daudz limenas jasadala objektu, un viena tabula ar n+1 laukiem, kur pirmais ir unicals
identifikators un citi – norades uz kadu limenu.
[numeracija
[pozicija
[mnemoniski
[liet. Valoda
12.
Klienta-servera arhitektūra.
Базы данных на персональных комп. развивались по направлению настольных, или локальных приложений,
когда реально с БД могло работать одно приложение, до систем коллективного труда.
Локальное приложение устанавливалось на единичном персональном компьютере, там же располагалась и БД,
с которой работало данное приложение. Однако необходимость коллективной работы с одной и тойже БД
повлекла за собой перенос БД на сетевой сервер. Приложение работающее с БД располагалось также на
сервере. Менее характерным был другой способ, заключавщийся в хранении приложения, обращавшегося к
БД, на конкретном компьютере пользователей. Были выпущены новые версии локальных СУБД, которые
позволяли создавать приложения, одновременно работающее с одной БД на файловом сервере. Основной
проблемой была обработка транзакций и неизбежно встающая при коллективном доступе проблема
обеспечения смысловой и ссылочной целости БД при одновременном изменении одних и тех же данных. В
ходе эксплуатации таких систем были выявлены общие недостатки фаил-серверного подхода при обеспечении
многопользовательского достуна к БД:

Вся тяжесть вычеслительной нагрузки при доступе к БД ложится на приложение клиента.

При выдачи запроса на выборку информации из таблицы вся таблица копируется на
клиентское место и выборка осуществляется на клиентском месте

неоптимально расходуются ресурсы клиентского компьютера в сети- сетевой трафик при
постоянном копировании всей таблицы, а не только нужных записей.

Большие затраты на модернизирование всех клиентских комрьютеров вместо одного
сервера.

Минимальная защита хранения данных, т.к. на фаил-сервере физически БД – это директория с
набором таблиц.

Недостаточно развитый аппарат транзакций для локальных СУБД служит потенциальным
источником ошибок, что нарушает смысловую и ссылочную целочность БД.
Приведенные недостатки решаются при переводе приложений из архитектуры «фаил-сервер» в архитектуру
«клиент-сервер», которая знаменует следующий этап в развитии СУБД. Характерной особенностью
архитектуры «клиент-сервер» является перенос вычислительной нагрузки на сервер БД (SQL server) и
максимальная разгрузка клиентов от вычислительной работы, а также существенное укрепление безопасности
данных – как при злонамеренных, так и просто ошибочных изменений.
Преимущества архитектуры «клиент-сервер»:

Большинство вычислительных процессов происходит на сервере

Снижаются требования к клиентским компьютерам

Понижается сетевой трафик, т.к. на запрос программы посылаются только нужные записи
из таблиц.

Легче и дешевле обновлять один сервер, чем все клиентские компьютеры.

БД на сервере, как правило, представляет собой единый фаил, в котором содержаться таблицы
БД, индексы и т.д. Взломать такую БД при наличии умысла значительно тяжелее. Т.к. с БД работает только
одна программа, то и намного увеличивается защита смысловой и ссылочной целостности БД. Также сервер
контролирует уровни досткпа клиента к БД.
Для реализации архитектуры «клиент-сервер» применяют «удаленные» СУБДб такие как MS SQL Server,
Borland InterBase, Oracle, Informix, Sybase, DB2.
13.
Datu vadibas sistema FOXPRO
Paaudzes:
Pavisam ir 4 paaudzes programesanas valoda.
1. Masinkods. Pirms 1965gada. Visas komandas ir nokodetas un ir ciparas. Problem: gruti lasama, viss ir absolutas
adreses, kompilatorta nav. Assembler (pec 1965gada)– viena komanda atbilst vienai ciparu comandai, bet bija ari
komandas kuri atbilst dazadam komandam. (atminas rezervesana u tt)
2. 1965-1975. Cobol – datu apstradei, fortran – matemakikiem. Algol.
2.5. aaudze – PL\1 – pvienojums no Asm, Cobol, Fortran, Algol. Bija loti populars. Liela un sarezdita valoda.
3. 1975-1990g. Pascal, Ada, Modula, Basic – attistibas datu tipas, pats lietotajs var defibet savus tipus. Paradijas
objekctu orientetas valodas (pascal 5.0)
4. pec 1990g. Datu bazes, objektu importesana(importetu objektu sistema), OOP, visualizacija(formas - objekti) –
Delphi, Visual C++, C++ Builder, Visual Basic, Lotus-Notes, Access, ForPro …
FoxPro ir interpritators:
Interpritatori: Izpilda visu programmu pec rindas (komandas).
Lietotajs->programma->interpritators->rezultats, dati->interpritators<-objektu moduli. Interpritatoram vajag atrast
rindas (komandas) numuru. +Nav jakompile – laika ekonomija. –atrdarbiba zemak ka stradajot ar kompilatoru, Lai
programmu izpildit ir vajadzigz interpretators.
14.
Kompilatori, interpritatori.
Lietotajs->programma->OS compilators->[objektu modulis]->[link editors]->izpildijamais modulis->OS izpilda>rezultats,.darbi->OS izpilda, DLL(SP DM)->limk editor
Kompilators sastada simbolu tabulu, izvieto mainigus atmina, treiso tekstu un nomaina rindu ar komandas kodu.
Optimizejoss K. - veido izpildijamo kodu pec izmantojamas atminas un pec laika. – atkariba no platformas, izpildas
kodu iegusanas laiks, liels izmers izpilditajam kodam.
programmu izpildit ir vajadzigz interpretators.
15.
Datu apstrades modelis FoxPro.
FoxPro ir interpritators:
Interpritatori: Izpilda visu programmu pec rindas (komandas).
Lietotajs->programma->interpritators->rezultats, dati->interpritators<-objektu moduli. Interpritatoram vajag atrast
rindas (komandas) numuru. +Nav jakompile – laika ekonomija. –atrdarbiba zemak ka stradajot ar kompilatoru, Lai
programmu izpildit ir vajadzigz interpretators.
FoxPro darbibas var veikt tikai ar vienu tabulu – tekojoso, bet var to mainit uz citu.Tabula var:

Uzbuvet tabulu – create table

Atvers pedejo (aktualo) tabulu – browse

Uzstadit tabulas norade – select <norade> use <vards>

Meklet tabula – seek

Par vienu uz priekšu – locate

Kartaja raksta izmaiņa – locate, skip

Atra meklēšana (tieša pieeja) – seek <ko mēs meklējam>
Kolonu vardus var kalpot par mainigiem programa.
16.
FOXPRO datu tipi
Character: teksta tips. Var izmantot jebkurus simbolus. Izmers 1-254 bytes
Currency: valutas tips. Izmers 8 bytes.
Date: datumu tips. Izmers 8 bytes. No 01.01.100 lidz 12.31.9999
Logical: logiskais tips. Izmers 1 byte. (true .T. vai false .F.)
Numeric: skaitlu tips. -0.999E+19 – 0.9E+20, 10bytes
17.
Tabulas un darbibas ar tam.

Radit tabulu

Datu ievads un maina

Pievienot rindinu

Likvidet rindinu

Rindinas satura izmaina

Vizualizacija

Likvidet tabulu
Par tabulu sauc tadu datu strukturu, kura parasti sastav no ierakstu virknes katrai no kuriem ir minimalais
identifikators, jeb atslega un satur kadas vertibas. Parasti tabulai ir kolonas, kuriem ir nosaukumi. Tabulai parasti
varetu but bezgaligi daudz rindinas(ierakstus). Tabulas var ari meklet informaciju pec dota atslega un veikt dazadas
darbibas.
?Parasti tabulu glaba atmina ka rakstumasivu, ka sarakstu ar noradem vai no pares masivu no dazadam datu tipiem,
kuriem ir kopiga indeksacijas shema.?
В каждой таблице БД может существовать первичный ключ.
Под первичным ключом понимают поле или набор полей, одназначно идентифицирующей запись. Значение
первичного ключа в таблице должно быть уникальным, то есть в таблице не досжно существовать записей с
одинаковым значением первмчного ключа. Первичный ключ должен быть минимально достаточным: в нем не
должно быть полей, удаление которых из первичного ключа не отразится на его уникальности. Уникальность
подобного поля обычно отслеживается или програмно или автоматически (в таблицах Paradox тип
Autoincriment).
По правил хорошего тона и из чисто практических соображений в таблице всегда должен быть определен
первичный ключ.
Нормализация таблиц: Процесс нормализации имеет своей целью устранение избыточности данных и
заключается в приведении к третьей нормальной форме. Всего существует 6 н.ф., но при практической
разработке важны первие при.
1-ая н.ф. – требует чтобы каждое поле таблици БД:

Было неделимым – означает, что значение поля не должно делиться на более мелкие значения.

Не содержало повторяющихся групп. Повторяющимеся являются поля, содержащие
одинаковые по смыслу сначения.
2-ая н.ф. – требует чтобы все поля таблицы зависели от первичного ключа, то есть первичный ключ
одназначно определял запись и не дыл избыточен. Те поля, которые зависят только от части ключа должны
быть выведены в отдельные таблицы.
3-яя н.ф. – требует чтобы в таблице не имелось транзитивных зависимостей между неключевыми полями, то
есть чтобы значение любого поля таблици, не входящего в первичный ключ, не зависело от значения другого
поля, не входящего в первичний ключ.
Но не всегда существует возможность привести все таблици БД к н.ф.
18.
Jedziens par SQL.
SQL(structured query language) – структурированний язык запросов. Он позволяет создовать и обрабатывать
реляционные базы данных, представляющие сабой набор связанных данных, хранящихся в таблицах.
Реляционная бала данных – это связанная информация, представленная в виде двумерних таблиц.
SQL – это язык ориентированный специально на реляционные базы данных. Он позволяет исключить
большую работу, исполняемую при использовании языка програмирования общего назначения. Команды SQL
могут выполняться над целой группой таблиц, как над единственным объектом, а также могут оперировать
любым количеством информации, которая извлекается или выводится из них как из единого целого.
SQL – это стандарт для работы с удаленными БД, состоит из комманд которие передаются программе
управляющей работой БД, предлагая ей выполнить определенные действия. Команды SQL состоят из
ключевых слов и аргументов. Ключевые слова – это слова имеющие специальное значение в SQL. Аргуметы –
это имена таблия, БД, полей таблиц (объектов), значения полей и т.д.
Существуют два SQL:
Интерактивный: применяется для выполнения действий непосредственно в БД с целью получить результат
который используется человеком. При применении этой формы SQL вводится команда, она выполняется, поле
чего можно немедленно увидеть выходные данные.
Встроенный: состоит из команд SQL, включенных в программы которые в большинстве случаев написаны на
каком-то другом языке програмирования. Такое включение может сделать программу более мощной и
эффективной, однако несовместимость этих языков со структурой SQL и присущим ему стилем управления
данными требует внесения ряда расширений в инткрактивный SQL. Выходные данные команд SQL во
встроенном SQL «заносятся» в переменные и параметры, использыемые программой в которую включены
предложения SQL.

Язык определения данных (DDL) – состоит из тех комманд, которые создают объекты в БД

Язык манипулирования данными (DML) – это множество комманд определяющих какие
данные представлены в таблицах в любой момент времени

Язык управления данными (DCL) – состоит из предложений определяющих может ли
пользователь выполнить отдельные действия.
19.
Indeksēšana.
1.
virknes pieeja. Pielietojumi – ja apstradē visu tabulu, grupas pieprasijumi.
2.
Tieša pieeja. Individuāla pieeja. Fiziska pieeja diskam. Sasaiste starp problemām datu orientēšanas un
uz diska atrašanas.
F(<raksta numurs>) = <fiziska adrese>.
Индексы представляют собой механизмы быстрого доступа к данным в таблицах БД. Сущность индексов
состоит в том, что они храеят значения индексных полей и указатель на запись в таблице. Следовательно, если
нужно выбрать все записи с определенным значением индексного поля, нет нужды просматривать всю
таблицу, достаточно найти в индексе построенном по столбцу заданное значение, первий указатель на запись
содержащию заданное значение поля и считать из таблицы эту запись, а затем повторить тоже для всех иных
указателей в индексе на записи с заданным значением. В действительности индексы имеют более сложную
организация, но думается что с логической точки зрения при проэктировании баз данных полезнее
представлять их структуру и их принцип использование так как это сделоно выше.
Существуют
Индексно-последовательный: Для выполнения запроса к таблице БД указатель в индексе устанавливается на
первую строку удовлетворяющую условию запроса, и считывается запись из таблицы по хранящимуся на ней
в индексе указателю. Затем указатель в индексе перемещается на следующую строку, удовлетворяющую
условию запроса, и из таблицы считывается запись. Процесс выборки прекращается, когда текущая строка в
индексе перестанет удовлетворять условию запроса. Метод назван индексно-последовательным т.к.:

Поиск ведется по индексу, а не по самой таблице

Поиск в индексе начинается только с первой строки, удовлетворяющей условию запроса.

Строки в индексе, начиная с такой записи, просматриваются все-таки последовательно.
Последовательный: Для выполнения запроса к таблице БД просматриваются все записи таблицы от первой до
последней, неэффективность выражается прежде всего в потере быстродействия и напрасной трате
вычислительных ресурсов. Время выполнения запроса прямо пропорционально числу записей в таблице.
Дополнительные индексы создаются в ручную или программно, если индексов, построенных по определениям
первичных и внешних ключей, недостаточно для:

Обеспечения нужного порядка сортировки данных

Оптимизации доступа к БД