1. DBMS
1.1. database
1.1.1. any collection of data
1.2. DBMS
1.2.1. software system designed to maintain database
1.3. when use DBMS
1.3.1. a large amount of data
1.3.2. security and integrity of the data are imoprtant
1.3.3. many user access the data concurrently
1.4. need meta data
1.4.1. data that describe the properties or charecteristics of end-use data and the context of those database
1.5. data heirachy
1.6. why we use dbms
1.6.1. without dbms
1.6.2. with dbms
1.7. DBMS architecture
2. RDBMS
2.1. Design data model
2.1.1. "What to concern
2.1.1.1. Data Integrity
2.1.1.2. Data relationship
2.1.1.3. Key
2.1.1.3.1. primary key
2.1.1.3.2. Foreign key
2.1.1.4. business rules
2.1.1.4.1. constraint relationship
2.2. database architecture
2.2.1. ER diagram
2.2.2. Entity
2.2.2.1. Table
2.2.3. Relation
2.2.3.1. Link to other table
2.2.3.2. create tehe composite value
2.2.4. Normal form
2.2.4.1. How to normalize the data
2.2.4.2. the level of data design
2.2.4.3. 5 level
2.2.4.3.1. only third level is ok
2.3. manipulation
2.3.1. CRUD
2.3.1.1. SQL - Structured Query Language
2.3.1.1.1. more likely the human phase
2.3.1.2. CREATE
2.3.1.2.1. CREATE DATABASE testDB;
2.3.1.2.2. CREATE TABLE Persons ( PersonID int, LastName varchar(255), FirstName varchar(255), Address varchar(255), City varchar(255) );
2.3.1.2.3. INSERT INTO Customers (CustomerName, ContactName, Address, City, PostalCode, Country) VALUES ('Cardinal', 'Tom B. Erichsen', 'Skagen 21', 'Stavanger', '4006', 'Norway');
2.3.1.3. READ
2.3.1.3.1. SELECT CustomerName, City FROM Customers;
2.3.1.3.2. using where cause
2.3.1.3.3. ORDER BY
2.3.1.3.4. join
2.3.1.4. UPDATE
2.3.1.4.1. UPDATE Customers SET ContactName = 'Alfred Schmidt', City= 'Frankfurt' WHERE CustomerID = 1;
2.3.1.5. DELETE
2.3.1.5.1. DELETE FROM Customers WHERE CustomerName='Alfreds Futterkiste';
2.3.1.6. SQL
2.3.1.6.1. Ansi standard
2.3.1.6.2. other tailor made
2.3.2. aggregation
2.3.2.1. summarize the data from rdbms
2.3.2.2. SELECT COUNT(ProductID) FROM Products;
2.3.2.3. SELECT AVG(Price) FROM Products;
2.3.2.4. SELECT SUM(Quantity) FROM OrderDetails;
2.4. Application
2.4.1. data which required consistency
2.4.1.1. data that always change
2.4.1.2. POS
2.4.1.3. User management
3. NoSQL
3.1. Design data model
3.1.1. Non sql or not only SQL
3.1.2. Regarding to the economic of scale of harddisk
3.1.3. the need of big data
3.1.3.1. require faster response
3.1.3.2. space is not limitation
3.1.4. Using different data structure and query methods
3.1.5. data structure
3.1.5.1. key value
3.1.5.1.1. store basic information
3.1.5.1.2. caching to get the data faster
3.1.5.1.3. Redis, Voldemort, Riak, and Amazon’s DynamoDB
3.1.5.2. column based
3.1.5.2.1. appropriate for big data and instances where data is relatively simple and consistent
3.1.5.2.2. Cassandra
3.1.5.2.3. HBase, Cassandra, HBase, Hypertable
3.1.5.2.4. data warehouses, business intelligence, CRM, Library card catalogs
3.1.5.3. Documented oriented
3.1.5.3.1. the value that is paired with a key is stored as a document.
3.1.5.3.2. Each document is self-contained, which means no schema is required –
3.1.5.3.3. giving a significant degree of flexibility over the data you have.
3.1.5.3.4. Amazon SimpleDB, CouchDB, MongoDB, Riak, Lotus Notes
3.1.5.3.5. any different types of websites and applications – from stores to content systems
3.1.5.3.6. elastic search
3.1.5.4. Graph base
3.1.5.4.1. The notable distinction about graph-based NoSQL databases is that they contain the relationships between different data. Subsequently, graph databases look quite different to any of the other databases abov
3.1.5.4.2. Neo4J, Infinite Graph, OrientDB, FlockDB
3.1.5.4.3. Use in fraud detection, logistic, spartial data
3.2. Decision of selection
3.2.1. Why nosql
3.2.1.1. Non relationship
3.2.1.2. schema free
3.2.1.3. simple api
3.2.1.4. Distributed
3.3. Application
3.3.1. Social network
3.3.2. Searching application
3.3.3. getting the fast response
4. Current trends, and practices
4.1. Data lake
4.1.1. The place where all data are long together
4.1.2. requires a good design
4.1.2.1. different data from the different source provides different schema
4.1.3. RDBMS still requires
4.1.4. data can be used in analytics
4.1.5. usage
4.2. Using the well design data
4.2.1. most application contains the patterns
4.2.2. using the design patern for the same problem
4.2.3. reduce many problem which may occur
5. Introduction
5.1. Database system management
5.2. What is data
5.3. What is database
5.4. How it is importance?
6. Data
6.1. What is the data
6.2. How can we store data
6.3. History of data
6.3.1. 1950 - 60 Sequenctial data magnatic tape
6.3.2. late 60 and 70 Hard disk
6.3.2.1. simple file collection
6.3.2.2. the in consistency of data
6.3.2.3. Relational database model
6.3.3. 1980's
6.3.3.1. sql become industrial standards
6.3.3.2. database become to the commerce
6.3.3.3. parallel and distributed database system
6.3.4. 1990's
6.3.4.1. Large decision support system, and data mining
6.3.5. early 2000
6.3.5.1. XML XQuery standards
6.3.5.2. Automated databased admin
6.3.6. Later 2000's
6.3.6.1. No SQL
6.3.6.2. Giant data storage system
6.3.6.3. Google BigTable, Amazon